With the development of the Internet and its related technologies, web applications and services are becoming more and more popular as well as important in the software industry. Among web technologies, Representative State Transfer (REST) has become one of the most ubiquitous and fast-growing technologies. There is an increasing demand for software to provide RESTful APIs to accommodate customized client-end user interface development and integration. Most development languages now include frameworks to build RESTful web services.
However, many existing implementations utilize the Common Object Request Broker Architecture (CORBA) which was developed during the Internet's infancy. CORBA is a software standard defined by the Object Management Group which many systems employ for cross-platform communication to maximize the advantages of different programming languages and manage distributed Network Element Services (NES). Consider C++ development for example, the native C++ development environment does not have native support for graphical user interfaces (GUIs), so C++ requires other development languages for the support of GUI development (e.g. JAVA). Likewise, CORBA uses interface definition language (IDL) to regulate the interfaces and objects presented to different implementations (e.g. C, C++, Java, Pascal, Python, Ruby) so that developers need not “re-invent the wheel” and develop cross-platform communication software, and by extension, save cost and time associated with development of such software systems. CORBA provides a well defined way of cross-platform communication where access is at the object level with much of the underlying client-server communication code hidden from the developer. Likewise, CORBA features a naming service that provides developers a simple way to register and look up the object references using logical names.
However, CORBA remains an impractical solution going forward due to non-trivial challenges. For instance, both client and server in the CORBA architecture require the same IDL to be utilized at runtime to ensure compatibility. A mismatch between IDLs can result in complete breakdown of communication between client and server. This makes CORBA implementations relatively brittle as even minor changes and upgrades to the exposed functions/methods require synchronization between server and all clients that may be impractical. Moreover, many existing solutions utilize some amount of propriety CORBA elements that require not only knowledge of CORBA itself but the nature of the changes to the core services. This proprietary knowledge can require extensive training and can unfortunately result in full, ground-up redevelopment of legacy CORBA software services rather than reuse of otherwise functional software.